home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1998 July / EnigmA AMIGA RUN 29 (1998)(G.R. Edizioni)(IT)[!][issue 1998-07 & 08].iso / recent / iib122.lha / IIB / Threads / phong_shade_prob < prev    next >
Internet Message Format  |  1998-04-25  |  5KB
  1. Date:         Thu, 16 Apr 1998 13:45:42 +0000
  2. From: Thomas Flindt Hansen <zzap@MAIL.COM>
  3. Subject:      [IML] IFW: phong shade trouble.
  4.  
  5. Hi all,
  6.  
  7. I haven't used Imagine for Windows for quite some time, but recently I
  8. found the time to sit down and play around with my fav. 3d program.
  9. Didn't play much though cos a really weird surprise awaited me. I can't
  10. recall having this problem before, I'm sure I'd remember then. It's the
  11. phong shade algorithm that's completely up the spout. Whenever I render
  12. in trace with a "cast shadow" light source, I get dark triangles along
  13. the line of the shadow on the objects. I have uploaded two pictures to
  14. illustrate what's happening. The first one is a default sphere (phong
  15. enabled) where the dark triangles are very prominent. It's at:
  16. http://www.geocities.com/heartland/3330/sphere.jpg
  17. The second picture shows a torus where you can both see the dark
  18. triangles AND all the other triangles that make up the torus object. It
  19. is phong shaded like the sphere, so the triangles shouldn't be visible,
  20. should they? It's at:
  21. http://www.geocities.com/heartland/3330/torus.jpg
  22. I got the same result with both version 1.3.4, 1.3.5 and also when I did
  23. a complete reinstall of version 1.0. Now the really weird thing is that
  24. when I transferred Imagine to my old 486, I got the same result, and a
  25. fresh install of version 1 on the 486 yield the same thing. I should
  26. have done it in the opposite succession to see if it was the old version
  27. that messed things up (the reg. base, MFC, whatever). What a bummer!
  28.  
  29. I know this list is not a tech support list (have contacted impulses
  30. tech support too), so sorry for the long entry, but I would like to know
  31. if anyone has experienced this too? Probably doing something really
  32. silly, I need someone to nail it for me!
  33.  
  34. ----------------------------------
  35.  
  36. Date:         Thu, 16 Apr 1998 14:52:02 PDT
  37. From: Ian Stearns <buzzbuzz@HOTMAIL.COM>
  38.  
  39. -groan- :)
  40. This has come up before and made noise for a week on the list.
  41. Short story is--it's a feature of phong. The 'dark-triangles' are just
  42. on the edge of the shadow...imagine has to make a choice on which side
  43. they ultimately are on...(either-or).
  44. This behaviour can be noted in most polygon renderers...not just
  45. imagine.
  46. Solution 1:
  47.   Fracture and Smooth.  This minimizes the problem...sometimes solves
  48. it.
  49.  
  50. Solution 2:
  51.   Change the angle of the light a weee bit.  (I also like
  52. fill-lights...which take away a lot of the contrast).
  53.  
  54. Good luck!  Get ready for the 20 replies to your question. :)
  55.  
  56. ----------------------------------
  57.  
  58. Date:         Thu, 16 Apr 1998 17:37:21 +0400
  59. From: Charles Blaquiere <blaq@INTERLOG.COM>
  60.  
  61. Thomas,
  62.  
  63. you've stumbled onto an unfortunate side effect of Imagine's new Gamma
  64. function. The black faces are facing away from the light source;
  65. anything over a 90-degree angle will do it. In olden days, before Gamma
  66. lightened things up, object shading was darker, and these boundary faces
  67. were lost in the darkness. With Gamma activated, the last faces that
  68. still face the light (i.e. have an light/face angle <90), are now much
  69. lighter, and you see the difference between them and their dark
  70. neighbours.
  71.  
  72. Here's my educated guess as to what's happening: part of the renderer is
  73. an algorithm to determine how much light is received by an object. When
  74. Imagine is about to render a pixel belonging to a face, I believe it
  75. first asks itself if that face is facing towards, or away from, the
  76. current light source. If facing away, then the entire face is considered
  77. to receive no light from that source, and the light-intensity algorithm
  78. exits immediately. If facing towards, then angle calculations, combined
  79. with the Phong algorithm, determine light intensity at that point.
  80.  
  81. Again, this is just a theory, but one that fits the facts at hand. You
  82. can see why Imagine would do this: why waste precious time playing the
  83. Phong game when a face isn't even lit by the source?
  84.  
  85. The problem, of course, occurs for borderline faces, those which, are
  86. turned away from the light source, but have at least one immeidate
  87. neighbour facing _towards_ the light.
  88.  
  89. The solution would be for Imagine to always perform Phong shading,
  90. regardless whether the current face is facing away from the light
  91. source. If a face's neighbours all faced away from the light source, the
  92. result would still be zero light intensity; however, if one of the
  93. neighbouring faces was turned towards the light, then the face currently
  94. under examination would be correctly lit. This would increase rendering
  95. time, as Imagine would perform Phong calculations on all faces, but it
  96. would ensure that those borderline faces would stop appearing as dark
  97. black holes.
  98.  
  99. At this point, I'd really like to get Mike's input on this.
  100.  
  101. ----------------------------------
  102.  
  103.